According to some very unscientific testing, current change cuts speed (and allocations) down by a factor of around 2. Still a couple of seconds on a fast machine to run rules() initially (hence the WIP), but this seems like something that could/should be resolved in the near future.

cc: @MasonProtter

Exciting!

Wait, is this related to #38? #38 is about compile times, not runtimes. (Runtime speed is important too of course)

From what I understood, #38 was meant to be about the speed of initially creating the rule set (by calling rules()), which is currently unreasonably slow the first time due to compilation. This leads to extremely slow normalization, even on smaller terms. Note that on subsequent runs, rules() is much faster (~100x - still not good real time, but more palatable), since Julia doesn't need to recompile the code for rules() generation.

Oh I see, I didn’t realize calling rules() was the culprit!

julia> using Rewrite

julia> @time rules();
  2.365382 seconds (3.59 M allocations: 179.190 MiB, 3.12% gc time)

julia> @time rules();
  0.017669 seconds (21.51 k allocations: 1007.078 KiB)

Seems like it has to be. 😅

It's probably worth it long-term to rethink how rules are actually stored (and how to cache them effectively), since currently we call rules() implicitly with every call to normalize. However, that will probably come alongside a major design overhaul.

Oh no, there's more!

julia> t = @term(1 - 2/2);
       rs = rules();

julia> @time normalize(t, rs)
  7.992327 seconds (10.88 M allocations: 547.837 MiB, 3.24% gc time)
@term(0)

julia> @time normalize(t, rs)
  0.015746 seconds (79.30 k allocations: 7.676 MiB, 43.38% gc time)
@term(0)

Probably related to #62.

It seems like matching might be the culprit - in hindsight, this makes sense, considering how often it's called and how expensive some of the operations involved are. Currently working to optimize it.

I've opened #67 separately, since it seems disjoint from these improvements.